The present invention relates to techniques for preventing fraudulent use of software products. In particular, the present invention provides a license management system and a technique for enforcing the use of a software product according to the corresponding license terms.
One of the most significant problems in software distribution is the protection of the rights of software producers and other subjects involved in software distribution. The subject holding the rights on a software product is very often distinct from the actual producer of it. Therefore, the subject owning the rights on a software product will be referred to as software supplier in the context of this discussion. Further, within the process of software distribution a subject acquiring licenses for a software product from a supplier and reselling those licenses to other distributors, dealers or end-users is defined as a distributor in this context. Hereby, the term dealer describes a subject which acquires licenses for further reselling them to other dealers or end-users, and an end-user is defined as a subject, which acquires a license on a software product for utilizing it.
The pricing scheme of a software product usually does not comprise only a single value, but a list of graduated prices reflecting considerations like the volume of an order and/or the number of installations of a software product already in use at a customer's site and/or if the customer is a governmental, commercial or educational end-user. This price range very often forms an incentive for fraud. For example, a price for an educational copy of a software product is usually calculated to be just a small fraction of the price to be paid for a copy of the same software product sold for commercial use. Dealers are therefore frequently tempted to sell a copy of a software product to a commercial end-user which has explicitly been acquired by the dealer at a substantially lower price for an educational end-user.
Another annoyance for software suppliers is software pirating and the distribution of bootlegs, which considerably reduces the achievable revenue. Software pirates prefer to act in countries where it is very difficult for a software supplier to get legal support in prosecuting malicious subjects. In the era of world-wide data transfer, software pirates can act from countries in which a software supplier does not get any legal support for stopping their wrongdoing. Therefore, a software supplier will in many cases be unable to enforce his license terms. A known approach for solving this problem is the integration of mechanisms in a software product, which makes it difficult for malicious subjects to create a bootleg of that software product.
A common way of realizing a protection mechanism against software, pirating is to apply a mark to the software distribution medium like e.g. floppy discs or CD-ROMs such, that it will be very difficult for a malicious subject to reproduce the mark on an illicit copy. Verification code is added to the software, which checks if the software is being run from the original distribution medium as soon as the user tries to run the software. Usually, this is done by searching the medium from which the software is being loaded for the mark that was applied by the software producer or supplier. If such a mark cannot be found, a continued program execution will be refused.
In the context of this application the term “verification code” generally refers to a piece of code and/or corresponding data contained in a piece of software that is suited to assist in protecting rights on the piece of software.
To outsmart a protection mechanism of the kind described, a software pirate can either copy the mark or remove the verification code. At copying the mark, the illicit copy is made looking exactly the same to the verification code as the original distribution medium. Alternatively, the protection mechanism can be eliminated by reverse engineering the software with the purpose of discovering the verification code and how it interacts with the remaining code. On successful reverse engineering, the verification code can finally be deactivated or removed completely. This secondly described method is generally referred to as “cracking”. A “cracked” copy would not have to bear the mark, because a “cracked” version of the software would not check for its presence.
A software supplier may alternatively to the described method require an end-user to register his software product and to pay the due license fee. According to one variant of this model, a supplier will send a key file to the requesting end-user who in turn stores this file on his computer. Verification code embedded in the software will prevent, that a malicious subject can run the software without a key file. However, a software pirate can try to reverse engineer the format of the key file and generate one of his own. This is an equivalent to the copying of a mark as described above. Of course, a software pirate may alternatively also in this case deactivate the verification code from the software so that the software can be run without a key file.
Both types of attacks, copying marks or generating key files on one side and “cracking” on the other side are in wide-spread use and cannot be fully defended against. A software producer can only try to discourage any attempt of “cracking” his software by making the process of reverse engineering and other forms of attack as difficult as possible by obfuscating the inner workings of his software.
Recently, a method used to protect media like digital images and video-audio recordings has been proposed to be applied to the field of software protection. Hereby, a secret message, a so-called watermark is hidden within the software product. Due to the fact that such watermarks may only be removed easily by someone who is in possession of the hidden secret used for the construction of the watermark, this technique provides a high level of software protection.
WO 99/64973 proposes a software watermarking technique wherein the watermark is formed by a special executional state of the software. When provided with a secret input sequence, the software application enters a state which in itself represents the watermark, whereby the state is comprised of data in the stack, heap, global variables, registers, program counters and the like of the software application. In other words, the watermark is constructed within the dynamically allocated data structures of the program as it is being executed. Like above, an attacker may employ reverse engineering to identify the watermark generating code. He might then remove the generating code and thus the watermark from the software product. The suggested canonical use of the watermark is a fingerprinting of the product. Fingerprinting means, that each individual copy of the software product is uniquely watermarked, thus allowing an identification of each particular copy of a software product. In other words, by the method of fingerprinting each individual copy of the software product is watermarked with a different watermark. But still, an attack of an adversary cannot be fully defended against.
Another approach to prevent abuse of utilization regulations is to monitor the use of a software product. In this context U.S. Pat. No. 5,925,127 proposes a system, wherein a check-in/check-out module installed on a computer running the software product provides the licensing information and a software monitor module running on the same machine verifies a usage of the software program module according to the license conditions. The proposed system is especially used for monitoring the use of rented software.
The system proposed in WO 99/04354 suggests a license management system for software, wherein an application program requests a license from a license management unit which re-checks the request with a number of license decision units. In case, a license cannot be issued to a copy of an application program, this copy cannot be executed.
Although those systems check certain parameters like e.g. “Is there a license?”, “Are all licenses used up?” or “Is there an attempt to use the program beyond the expiration date of the license?”, a correct usage of the software program according to a contractual provision—part from the requirement that a license must exist at the site of the end-user cannot be guaranteed. Further, no provisions are suggested for warding off common impersonation attacks, where a malicious user sets up a fake license management unit unconditionally granting the execution of the application program, or replay attacks, where messages sent by the license management unit are recorded and later replayed for allowing an application program to execute without actually having to contact the license management unit.
Moreover, existing systems typically implement the license storage in a component that is accessible to the user of a piece of software, e.g. in the form of a software module installed on the same computer as the licensed piece of software or another computer accessible to the licensee. This enables a malicious user to attack the license enforcement mechanism by manipulating the component such, that it unconditionally confirms the presence of a license, even if no valid license exists for a certain software product.
In addition, existing protection systems typically require the programmer to add support for license enforcement, e.g. verification code, to his program manually. However, since most programmers are not security experts and hence not aware of how an attacker works, they do so in a way that greatly simplifies “cracking” their software.